About Uncertainty in Software Development
Public.icon
Conclusion: It is impossible to "plan" software development, so let's make it with Agile.
Reason: The development method of "budget and plan" in Waterfall is not useful for software with high uncertainty (unlike mass production such as factories). No one knows if the problem can be solved with the plan decided at the beginning.
It is difficult to predict resources for developing products to solve problems.
Specifics: What is "uncertainty" in software development?
1. It is not known whether the product to realize the solution actually solves the problem.
Actually, I made the product, but it didn't solve any problems.
/emoji/twitter.icon When you cut out a process chart or numerical target, there is a strong incentive to achieve only the appearance of the target. You need to set incentives to improve the quality of the product, but because there is no stable methodology for managing quality, you end up managing quantity. As a result, departments that are making efforts to improve quality become a hindrance.
2. Even if the problem is actually solved, it is not known whether it will be profitable.
The context may change, causing the situation to change significantly during the development period, and the problem to be solved may disappear or change.
This cannot be predicted by pre-data analysis.
3. Resources such as period, personnel, and risk countermeasures cannot be accurately predicted when developing a product to realize a solution (the larger the period and scale, the more prominent this is).
In the first place, "software development" itself cannot identify the period or necessary resources for production.
Why do people want to make a "plan" even though there is uncertainty as described above?
Conclusion: Because no one will pay without a plan.
Reason: The ordering party is looking for a "reason to pay".
Therefore, the developer side presents "budget and plan" (not world lines).
Specifics: Many people develop software in the following flow:
1. When trying to solve a problem, IT solutions come up.
2. Estimate the time and cost required to implement the solution.
3. Approval from the person who pays the money (budget confirmation).
4. Create a detailed plan and secure resources.
5. Just make it somehow.
Then, there are "failures (and fictions called failures)" like the following:
Budget overruns and plan delays
If the above two exist, even if you know that what you are making is "useless," you have no choice but to be passive about correcting the trajectory.
Spend a lot of time and money creating useless garbage.
Conclusion: "Budget and plan" is a concept that ignores the uncertainty in software development.
"It may not be a silver bullet, but it may be a 'steel bullet' concept called '[Agile'" Value individuals and interactions over processes and tools,
Working software over comprehensive documentation,
Customer collaboration over contract negotiation,
Responding to change over following a plan.
We value the items on the left more, but recognize the value of the items on the right.
Conclusion: We need to move away from the idea of budget and plan and face the "uncertainty in software development."
Specific example: How to deal with uncertainty
I want to create a never-ending Kaizen system (by Mr. Fukatsu)
For example, hypothesize "Will implementing this strategy increase profits?" and conduct an A/B test between Group A, which implemented the strategy, and Group B, which did not, then statistically verify the results several months later. Hypothesis verification should be a skill that every team possesses. Ideally, one team should be involved in the target business, department, or service indefinitely and continually conduct hypothesis verification.
The concept that "it's okay to use external systems."
Using the feature of software observability to improve problem resolution.
The systems of local governments and administrations often use waterfall ("budget and plan") for development. This is sometimes referred to as a "big business thing," but if a large company can overcome this, it can become an unbeatable enterprise. Thus, DMM is large in terms of meaning, but it has been fragmented into many divisions (whether this is good or bad is irrelevant). There are challenges in systems that the public uses more than private individuals. This article is good at explaining the differences between the demands placed on "public systems" and those placed on "privately owned systems". "Utilize tax money to provide the minimum-functionality services as public services to further develop the economic market."
However, when developing software, it is inevitable that it must be done in an agile manner.
People from various industries are participating more and more, and the most interesting phase is to work together to make Japan better. It is gratifying that people who have achieved results in the private sector are returning to the country and region in this way, and I want to create the future together with such people.
I think that contributing to OSS, applying for a job at the Tokyo Metropolitan Government, and participating in our Civichat are the best ways to see this future from the front row.